\chapter{Demo implementation and Results}
\label{cha:5}

This chapter will go deeper into the implementation of the agents design
in combination with the simulation environment. Also the demo setup and
scenarios will be discussed here. The first we need  a specific problem and a simulation
environment before we could implement our solution on it.

The design of the previous chapter will be extended with real roles that execute
code, a real capability and communication methods to synchronize the agents with
the simulator.

In this chapter we will refer to the source of OSGi bundles and the simulator.
The source code is available on the CDROM, that is delivered with the thesis.
More info can be found in appendix \ref{app:A}.

\section{Problem description}
The specific problem is variant of the GPDP problem. Packages must get from
point A to point B but with a stop at a depot. So some trucks must pickup packages and
bring them to the depot. Other trucks must bring the packages from the depot to
the delivery location. It looks like bringing a package from point A to the
depot is the same as bringing the package from the depot to point B. We will
assume that they are complete different roles. And on the level of code, it
is different.

At initialization a truck allready have some tasks they need to finish. 

This are the two roles we will implement :

\begin{itemize}
  \item Role1 : Will handle the task where a package needs to be delivered at
  the depot.
  \item Role2 : Will handle the task where a package must be picked up at the
  depot and must be dropped off at the delivery point.
\end{itemize}

The two types of tasks are completely independant. When the package is
deliverd at the depot the first type of task is done. After that a new task of
type two comes available. 

Agents are in OSGi and they control the trucks in the environement. Agents
handles the tasks, and it will send the truck the point of interest and the
ID of the package. The rest is automated by the trucks in the simulator. The agents
need to be synchronized with the trucks to foresee them with new information and get
updates from the trucks.


\section{Simulation environment}

To set up a demo for testing the solution we still have to choose our
simulation environment, extend our OSGi based agent and make a connection
between the agents and the simulator.

A simulation environment called Rinsim will be set up first. There we specify
wat we need according to the problem description. Afterwards we will implement
the connection between the agents and the simulator. Eventually we extend
the agent with the roles.

The figure \ref{fig-rmi} explains how the RMI interfaces are built up in our
application. The red bars represent the dependencies between the bundles. while
the blue rectangles represent OSGi bundles, the purple rectangles are ordinary
java classes or interfaces. Off course the RMI interfaces of the agents are
parts of the bundle. The arrows in the design stand for wich RMI interface is
reachable by the class or bundle. So will Role2 only access the
DropoffInterface.

This is only an example with two agents. The first agent has another layer
between the role and the RMI interface. Such a layer is not
there in the other agent. The bundle Capability1 represents the capability or
the extra resource the role needs before it can work.


\begin{figure}
  \centering
  \includegraphics[scale=0.7]{fig/demo_impl}
  \caption{RMI connections between the agents and the simulator}
  \label{fig-rmi}
\end{figure}

\subsection{Rinsim} 

RinSim\cite{website:rinsim} is a Java based simulation environment for multi
agent systems written in Java. More specifically for the pickup-and-delivery
problems. This simulator has been used in lab classes for multi-agent systems
and since I have some experience with the simulater, I chose to use this
environment to present a demo.

This simulator provides a framework that is easy to extend with new models and
ideas. It already provides several communication methods that are
customizable. Also this environment can work with scenario's. This is an
interesting thing for testing different solutions with the same scenario. 

``Physical'' objects like trucks and packages are already defined
in some demos but new objects can easily be added.

This framework also allows to split up the ``physical'' part from the
agent part. This is an interesting part because we will only use the
physical part of the simulator. The agent-side in our simulations will executed
in the OSGi environment.

In our solution we have three different ``physical'' classes : A truck, a
package and a depot. The Truck class will be extended two times, in a TruckOne
and a TruckTwo class, just a simple extension without extra functionality. We created
those extensions to let the simulator differentiate the two classes. In that way
the simulator assign a different color in the graphical user interface. The
color will classify which role they own at initialization.

Here are the physical objects that will be used in our demo :

\begin{itemize}
 \item Truck : The entity that moves around, it can pickup one pakage at a time
 and will also need to drop off packages.
 \item Depot : Is an object that does not move. It can only store packages.
 \item Package : An entity that will be picked up and must be delivered.
\end{itemize}

As we started from the examples provided in the simulator we also extended some
events for the scenarios.


\subsection{RMI \cite{website:rmi-tut}}

Rinsim and the OSGi based agents work in different execution environments. So
communication between the agents and the simulation environment cannot
happen directly. Therefore we needed some kind of communication between the
environments so that the agents can pas actions to the demo and that there could
be some synchronization between the environments. Since the environments all
work in Java we chose to implement Remote Method Invocation(RMI). 

RMI is a way where Java objects can communicate with eachother while they reside
in a different virtual machine. RMI is a client server based architecture.
Clients can invoke a function or method on the server that will return some
result. Also objects can be returned, but the client's classloader must have
knowledge of the type of object and the objects must be serializable. Since
we will have many agents and just one simulator, we can infer that the agents
must be clients and the simulator acts as the server.

On other use of rhe RMI interface is for agents to get a conversation ID. Since
their was no central space where agents could request a new conversation ID, RMI
was also useful since the server could be that central place that keeps overhead
for that ID.

\subsubsection{Interfaces}

In Rimsim a position on the map is defined by the class Point. This is actually
a x and y value as a double. Since RMI needs that a class is
known on both sides and the class must be serializable we just used the
x and y value instead of the Point class to exchange between client and server.

\begin{itemize}
 \item Serverinterface : This interface synchronizes and initialize every agent
 with the demo environment. Every agent and the demo environment each run in a
 different virtual machine. So it is preferred to synchronize each agent with
 it's 'physical' state in the demo environment.
\item 	pickupinterface : This interface is meant to give the order to the physical entity of the agent to go pickup 
a package and deliver it at the depot. Parameters are here the package ID,
pickup location x and y, agent name.
\item 	dropoffinterface : This interface is meant to give the order to the truck to go get a package at the depot and deliver it at the delivery location. Parameters
 are here the package ID, delivery location x and y, agent name.
\end{itemize}

\subsubsection{Server}

The interfaces are implemented in the RMIServer class. This class also has
access to the controller of the environment and so also to all the objects in
the simulator. 

Also a helper class InitTask is made along the ServerInterface. This class is
serializable and will help us to initialize tasks between the agent and the
simulator. Random points, to create the pickup and dropoff points for new
packages, must be generated in the simulator. Since the simulator also handles
the time, this information must be sent to the agents so that they can handle it
as real tasks. All the information for a new task will be encapsulated in the
initialization tasks and will be sent to the corresponding agents. The trucks in
the simulator don't know anything about those initialization tasks and will only
be addressed by the agents about any task.

Most functions in the interfaces need the agent's name as an
argument. When an agent performs an invocation of a such method on the server,
it will have to give  his own name. In that way the server will know to which truck
the invocation belongs to . 

\subsubsection{Client}

The first idea was to integrate only the needed interface in the Role-components. 
But integrating the multiple RMI-clients in such a way gave problems. All the
interfaces must be accessed by the same object. For that reason we need a single
RMI service component where all the interfaces are combined in one bundle.

 The bundle be.kul.osgi.ds.rmi connects the agent-middleware to the
 demo-environment. A short description of the bundle will be given here but more
 details will be given in the paragraph concerning the demo implementation. The
 demo environment RinSim is the RMI server that contains the 3 interfaces.

To simulate that the one Role only accesses code to execute a pickup, the code
in Role1 only has a function that can access the pickupinterface. The other role
can only accessc the dropoffinterface

\section{Agent implementation for the demo}

\subsection{Roles}

The one thing that will define if an agent can execute some kind of task is that
the he must have the associated role. From the problem description we defined
two different roles. Those two roles must implement the IRole interface like
described in the previous chapter. 

Both the bundles contain a class Role, Task and TaskState. The class Role will
represent the service object because of the implementation of IRole. The other
two tasks are also exported, thus visible. The class Task implements ITask so
that the agent can easily interface the standard fields for scheduling. All
the classes, in each bundle that represents a role, are unique for each role.
That has as the result that mixups in classes cannot occur. 

Every role bundle has it's own executable code and is defined like this :

\begin{enumerate}
\item Bundle be.kul.osgi.ds.Role1 : This bundle depends on a dependency. That
dependency depends on RMI, but only contains the code that interfaces the
PickupInterface
\item Bundle be.kul.osgi.ds.Role2 : This role depends on the RMI, and only can
execute the code that interfaces the DropoffInterface
\end{enumerate}


\subsection{SynchronizationThread}

In the bundle be.kul.osgi.ds.myagent we also have made a class SyncThread. This
is the thread that keeps the agents synced with the simulator.

RMI is the chosen technology to establish the communication between the agents
and it bring some limitation with it. RMI has a client-server architecture that
works following the request and response principle. So when an agent(client)
wants to know something from the demo environment (server) the agent must
perform a request and it will be responded. To do some synchronization between
the agent and the environment, the agent is equipped with a
synchronization-thread that will poll the server at fixed intervals. 

Another approach with RMI was also possible. It is possible to create
eventlistener such that the server informs the client with events so that the
client does not have to poll constantly to synchronize. This method was not so
easy to implement and since the overhead of synchronizing was not that much the
polling method was kept for use.

\begin{enumerate}
\item Check the ID of the current Task that is being handeled by the
agent/truck in the simulation environment. If the Task is done or the truck is
idle it will return null;
\item If the agents and the server are not initialized yet. Initialize
everything for starting the simulation.
\item If the simulation is running, and if the check of the current task
returns null, send the next task to the corresponding truck.
\item Check if the truck is broken or not. If it is broken, start exchanging all
the tasks.
\end{enumerate}


\subsection{Bundle : be.kul.osgi.capability1}

This bundle is created to test the code migration of a capability or resource.
Normally the code migration is only the executable code but in some cases the
executable code depends on another software or hardware layer. To simulate the
migration of such a resource, we added a layer between Role1 and the RMI
bundle. It was possible to just connect the RMI bundle directly to the role
bundle. We chose to add a layer in between to express the power of the agents
that they can also exchange the resources. Another possibility was to made a
role depend on a dummy Bundle and it can also express the power of our solution.
On the other hand, a layer in between the role and the RMI interface contains
interaction code and presents a more realistic image of the problem.

This bundle is also made as a DS and dependencies and service offerings are
declared in the service component. The bundle only contains one
class that represents the service object. This class contains the bindings for the RMI service and all the
functions to execute the the functions of RMI. 


\section{Demo}

This section will explain the scenario of the demo. Due time
issues this will be a very small demo where not all of the implementations can
be tested.

\subsection{Scenario}

In the scenario we start with three trucks. One truck only owns Role1 and
will pickup packages and brings them to the depot. The other two trucks are
owners of Role2. They will go get a package at the depot and bring it to the
destination. All the truck are initialized with 5 Tasks each. After a while the
first truck will brake down and no other truck with Role1 can direclty take over
the tasks from that truck. The truck will now try to exchange all of the tasks
to the other trucks together with the Role and the dependencies if needed. 

\subsection{Results}

When running the proposed scenario all the agents will have tasks in their
schedule. They will start to execute them. We can see at the color of the
agents what role they have at the initialization. At runtime the color will not
change to keep the overview on the trucks and agents.
As the agents are working, the only 
agents that plays the first role will break
down.At that point he may have been carrying a package and will drop that package back in to the environment. The
agent will start exchanging his tasks and the other agents must take over
thos tasks together with the role. Now those other two agents are playing
the two roles.

